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© Data packets (96) are delivered through a con- 
stellation (11) of nodes (12) to a termination unit (18, 
20, 22). The node where a packet leaves the con- 
stellation is a terminal node. Each packet includes a 
routing code (100). When a node receives a packet, 
it examines the routing code to determine if that 
node might be the packet's terminal node. A table 
look up operation is performed using the routing 
code as an index to a routing table (54). The table 
identifies a link (16) to use in routing the packet 
away from the node to a neighbor node. The packet 
is also examined to verify compatibility between 
packet type and a selected link. When a node con- 
cludes that it might be a terminal node for a packet, 
it evaluates a channel identifier (102) to determine if 
it is currently serving the party to whom the packet 
is directed. 
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TECHNICAL FIELD OF THE INVENTION 

The present invention relates generally to com- 
munication networks. More specifically, the present 
invention relates to selecting paths for delivering 
communications through a network of switching 
nodes. 

BACKGROUND OF THE INVENTION 

Communication networks, such as those used 
to deliver telecommunications, to interconnect com- 
puters, and the like, may include any number of 
nodes. The networks may deliver electronic com- 
munications between two points by routing the 
communications from node to node within the net- 
work. As the number of nodes in a network in- 
creases and as the number of communication 
paths available to each network node increases, the 
number of potential paths available for delivering 
any single communication likewise increases. Ac- 
cordingly, the problem of selecting an appropriate 
path through the network arises. Typically, a net- 
work attempts to select the shortest possible path 
to minimize delay, consume a minimal amount of 
network resources, and to maximize reliability in 
delivering a communication. At the same time, a 
network needs to balance this concern with a need 
to prevent communication traffic bottlenecks and a 
need to achieve the highest possible probability 
that a communication will be delivered to its in- 
tended destination. 

Conventionally, a static communication delivery 
path through a network is established prior to the 
actual delivery of a communication. In other words, 
a static delivery path is cleared during a call setup 
mode, which takes place before communications 
commence. A certain amount of network resources 
are dedicated to clearing the static path during call 
setup. However, once the static path has been 
cleared it remains allocated to the upcoming call 
until the call terminates. 

While this conventional static signal routing 
technique adequately serves the needs of a static 
environment, it fails to meet the needs of a dy- 
namic environment. In particular, when the network 
delivers communications between two points that 
move relative to the network, a dynamic path defi- 
nition is needed to compensate for movement. For 
example, the physical assets, or switching nodes, 
which are advantageous choices in routing signals 
between two points at call setup become disad- 
vantageous choices as the call progresses due to 
movement. 



SUMMARY OF THE INVENTION 

Accordingly, it is an advantage of the present 
invention that a network is provided which dynam- 
5 ically routes communication signals. 

Another advantage of the present invention is 
that network resources dedicated to routing com- 
munication signals are minimized. 

Another advantage is that the present invention 
70 distributes routing decisions among network nodes. 

Another advantage is that the present invention 
minimizes delay in delivering communication sig- 
nals between network entry and exit points. 

Another advantage is that the present invention 
75 compensates for communication traffic congestion. 

The above and other advantages of the present 
invention are carried out in one form by a method 
of routing a signal through a switch which serves 
as one node in a constellation of switching nodes. 
20 The method calls for receiving a data packet hav- 
ing a routing code therein. The data packet repre- 
sents at least a portion of the signal being routed. 
A link identifier is obtained in response to the 
routing code included in the data packet. This link 
25 identifier specifies one of a plurality of communica- 
tion links useable at the switch in routing the data 
packet away from the switch. The data packet is 
then transmitted away from the switch over this 
one communication link. 

30 

BRIEF DESCRIPTION OF THE DRAWINGS 

A more complete understanding of the present 
invention may be derived by referring to the de- 
35 tailed description and claims when considered in 
connection with the Figures, wherein like reference 
numbers refer to similar items throughout the Fig- 
ures, and: 

FIG. 1 shows a layout diagram of an environ- 
40 ment within which an embodiment of the present 
invention is practiced; 

FIG. 2 shows a layout diagram of switching 
nodes in a communication network, jurisdictions 
corresponding to the switching nodes, and com- 
45 munication links between the switching nodes; 

FIG. 3 shows a block diagram of a single switch- 
ing node, or switch, of the communication net- 
work; 

FIG. 4 shows a flow chart of a Background 
so procedure performed by switching nodes of the 
communication network; 

FIG. 5 shows a flow chart of a Switch procedure 
performed by switching nodes of the commu- 
nication network; 
55 FIG. 6 shows a data format diagram used in a 

first embodiment of the present invention to 
communicate data; 
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FIG. 7 shows a data format diagram used in a 
second embodiment of the present invention to 
communicate data; 

FIG. 8 shows a data format diagram used to 
convey a routing code; 

FIG. 9 shows a data format diagram used to 
convey a logical channel identification (LCID) 
value; and 

FIG. 10 shows a flow chart of a Terminal Node 
procedure performed by switching nodes of the 
communication network. 

DETAILED DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 



FIG. 1 illustrates a satellite-based communica- 
tion network 10. Network 10 includes a constella- 
tion 1 1 of switching nodes 1 2 that are dispersed 
around the earth. In the preferred embodiment, 
nodes 12 are orbiting satellites. Satellites 12 oc- 
cupy polar, low-earth orbits 14. In particular, the 
preferred embodiment of network 10 uses seven 
polar orbits, with each orbit holding eleven sat- 
ellites 12. For clarity, FIG. 1 illustrates only a few of 
these satellites 12. 

Orbits 14 and satellites 12 are distributed ar- 
ound the earth. Each orbit 14 encircles the earth at 
an altitude of around 765 km. Due to these low- 
earth orbits 14, satellites 12 travel with respect to 
the earth at around 25,000 km/hr and complete an 
orbit in around 100 minutes. Together, satellites 12 
remain relatively stationary within constellation 11 
with respect to one another, except for their orbits 
converging and crossing over each other in the 
polar regions. 

FIG. 2 presents an exemplary static, two di- 
mensional "snap-shot" map of the relative orienta- 
tion of a few of satellites (SVs) 12. With reference 
to FIGs. 1-2, at any given instant satellites 12 in 
even orbital planes 14a typically reside at approxi- 
mately the same latitudes. Likewise, satellites 12 
typically reside at approximately the same latitudes 
for all odd planes 14b. However, odd-plane sat- 
ellites 12 are positioned out-of-phase with even- 
plane satellites 12. At any given instant, the lati- 
tudes of odd-plane satellites 12 are approximately 
half way between the latitudes for nearby even- 
plane satellites 12. 

A line-of-sight exists between each satellite 12 
and fore and aft satellites 12 in the same plane 14 
and between fore and aft satellites 12 in adjacent 
planes. With reference to FIG. 1, a line-of-sight also 
exists between satellites in non-adjacent orbital 
planes 14 as the orbits converge near the polar 
regions. The preferred embodiment employs RF 
communications, preferably in the 20-30 GHz 
range, to establish communication links 16 between 
each satellite 12 and its "neighbor" satellites 12. 
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Links 16 are referred to as cross links herein to 
distinguish them from the links used by signals for 
entry into and exit from constellation 1 1 . With refer- 
ence to FIG. 2, up to six line-of-sight, bi-directional, 

5 RF communication cross links 16 are supported for 
each satellite 12. Fore and aft cross links 16a and 
16b exist between a satellite 12x and the preceding 
and following satellites 12a and 12b, respectively, 
orbiting in the same plane 14 (i.e. in-plane sat- 

w ellites). Fore-right and aft-right cross links 16c and 
16d exist between satellite 12x and the preceding 
and following satellites 12c and 12d, respectively, 
orbiting in a right side adjacent plane 14 (i.e. cross- 
plane satellites). Likewise, fore-left and aft-left cross 

75 links 16e and I6f exist between satellite 12x and 
the preceding and following satellites I2e and 12f, 
respectively, orbiting in a left side adjacent plane 
14. 

For purposes of the present invention, satellites 

20 12a-12f are referred to as neighbor satellites to 
satellite 12x. In particular, neighbor satellites nodes 
are those constellation nodes to which messages 
may be sent and from which messages may be 
received without requiring the messages to pass 

25 through any other node. This definition includes 
nodes which may not be in adjacent orbital planes 
but which nevertheless are within a line-of-sight 
due to the convergence of orbital planes 14 in the 
polar regions. In the embodiment of the present 

30 invention depicted in FIGs. 1-2, communications 
may be delivered only to neighbor nodes. Each 
satellite 12 supports a similar set of cross links 16 
and neighbor nodes. - 

While FIGs. 1-2 and the above-presented dis- 

35 cussion describe a preferred orbital geometry for 
network 10, those skilled in the art will appreciate 
that the switching node which each satellite 12 
provides need not be positioned as described here- 
in. For example, such nodes may be located on the 

40 surface of the earth or in orbits other than those 
described herein. Likewise, the precise number of 
switching nodes may vary from network to network, 
the number of cross links 16 supported by each 
node may vary from network to network, and the 

45 population of switching nodes with which each 
node may directly communicate need not be limit- 
ed to nodes physically nearby. 

With reference back to FIG. 1, satellites 12 
communicate with devices on the ground through 

so many central switching offices (CSOs) 18, of which 
FIG. 1 shows only one, a few ground control sta- 
tions (GCSs) 20, of which FIG. 1 shows only one, 
and any number, potentially in the millions, of radio 
communication subscriber units 22, of which one is 

55 shown in FIG. 1. Subscriber units 22 may be lo- 
cated anywhere on the face of the earth. CSOs 18 
are preferably distributed over the surface of the 
earth in accordance with geopolitical boundaries. In 
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the preferred embodiment, each satellite 12 may 
communicate with up to four CSOs 18 and over a 
thousand subscriber units 22 at any given instant. 
GCSs 20 preferably reside in the northern or south- 
ern latitudes, where the convergence of orbits 14 
causes a greater number of satellites 12 to come 
within direct line-of-sight view of a single point on 
the surface of the earth with respect to more equa- 
torial latitudes. Preferably, around two to four GCSs 
20 are used so that all satellites 12 in the constella- 
tion may at some point in their orbits 14 come 
within direct view of their assigned GCS 20. 

Nothing prevents CSOs 18 and GCSs 20 from 
being located together on the ground. However, 
CSOs 18 serve a different function from that of 
GCSs 20. GCSs 20 preferably perform telemetry, 
tracking, and control (TT&C) functions for the con- 
stellation of satellites 12. 

Preferably, CSOs 18 operate as communication 
nodes in network 10. Diverse terrestrial-based com- 
munications systems, such as national public 
switched telecommunications networks (not 
shown), may access network 10 through CSOs 18. 
Due to the configuration of the constellation of 
satellites 12, at least one of satellites 12 is within 
view of each point on the surface of the earth at all 
times. 

For purposes of the present invention, each 
end of a communication may be viewed as having 
a terminal node. The role of a terminal node is 
played by the one satellite 12 in constellation 11 
that routes the communication away from constella- 
tion 11 toward the earth. The terminal node may 
deliver a communication to a CSO 18, a GCS 20, 
or a subscriber unit 22. 

Accordingly, network 10 may establish a 
bidirectional communication circuit or two unidirec- 
tional circuits through constellation 11 of satellites 
12 between any two subscriber units 22, between 
any subscriber unit 22 and any CSO 18, or be- 
tween any two CSOs 18. However, these commu- 
nication circuits use different nodes of constellation 
1 1 from moment to moment for delivering commu- 
nications. The nodes change in response to the 
■ movement of constellation 11 with respect to the 
earth. 

In addition to the above-discussed relationship 
between satellites 12 and cross links 16, FIG. 2 
shows two jurisdictional patterns related to sat- 
ellites 12. FIG. 2 shows a pattern of circles 24 
arranged so that each satellite 12 resides at the 
center of a circle 24, so that every point in FIG. 2 
resides within at least one of circles 24, and so that 
a minimal amount of overlap between circles 24 
results. Circles 24 roughly indicate lines of equal 
signal strength for RF communications broadcast to 
the surface of the earth from each corresponding 
satellite 12. Accordingly, circles 24 roughly define 
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the geographical jurisdiction on the earth of each 
satellite 12. In other words, a CSO 18, GCS 20, or 
subscriber unit 22 may communicate with a sat- 
ellite 12 within whose jurisdiction it resides. Since 

5 satellites 12 move relative to the earth, circles 24 
likewise move. Those skilled in the art will appre- 
ciate that nothing prevents the division of circles 24 
into smaller cellular patterns to improve the geo- 
graphical reuse of the frequency spectrum allo- 

w cated to each satellite 12. Moreover, those skilled 
in the art will recognize that the boundaries in- 
dicated by circles 24 are not defined with precision 
in actuality. 

FIG. 2 additionally shows a pattern of space 

75 regions 26. Each space region 26 is represented 
by a unique static hexagon. Regions 26 are static 
because they do not move with respect to the 
earth. Thus, satellites 12 and circles 24 enter and 
exit regions 26 due to the movement of satellites 

20 12. FIG. 2 illustrates space regions 26 as equal 
size hexagons having a diameter approximately 
equal to the diameter of circles 24. Thus, no signifi- 
cant overlap occurs between regions 26, and re- 
gions 26 collectively cover the entire surface of the 

25 earth. However, those skilled in the art will appre- 
ciate that any number of regions 26 may be de- 
fined, that other shapes may be adopted, that all 
regions 26 need not have the same shape or size, 
and that no set geometric relationship needs to 

30 exist between regions 26 and circles 24. For exam- 
ple, space regions 26 and circles may both be- 
come reduced in size near the polar regions to 
compensate for the convergence of the orbits. 

In the preferred embodiment of the present 

35 invention, approximately 77 space regions 26 are 
defined. Although this number achieves a desirable 
one-to-one correspondence to the number of sat- 
ellites 12 in the preferred embodiment of the 
present invention, it is not a critical feature. On the 

40 other hand, a unique one of 77 possible space 
regions may be specified with a seven bit number, 
which is a relatively small amount of data to use in 
communicating world-wide geographic data. More- 
over, with 77 space regions approximately the 

45 same size as circles 24, each space region 26 fits 
within the collective jurisdiction of a particular one 
of satellites 12 and the neighbor satellites to this 
one satellite 12. 

Circular patterns 24 and space regions 26 are 

so useful because they illustrate two diverse routing 
embodiments contemplated by the present inven- 
tion. In both embodiments, signals are encoded as 
digital data packets, and each packet includes a 
routing code. Moreover, this routing code is desir- 

55 ably communicated using a relatively small amount 
of data, such as seven or eight bits. For each call, 
constellation 1 1 (see FIG. 1 ) may deliver thousands 
of such data packets. Thus, the use of only a few 

4 




7 EP 0 

routing bits in each data packet saves network 
resources compared to implementations that re- 
quire more elaborate routing codes. 

In one embodiment of the present invention, 
referred to below as a space region embodiment, 
the routing code identifies the space region 26 to 
which the data packets are directed. In this space 
region embodiment, all nodes 12 include sufficient 
intelligence to route data packets to a node 12 
serving the identified space region 26. Once the 
data packet arrives at the indicated satellite or 
node 12, the data packets are passed on to the 
earth, either by this node 12 or by a neighbor node 
12. The entities setting up a call and participating 
in the call need not be aware of the precise nodes 
12 used in delivering data packets or of changes in 
the identities of these nodes 12 over the course of 
a call. 

In another embodiment of the present inven- 
tion, referred to below as a physical node embodi- 
ment, the routing code identifies a particular 
switching node or satellite 12 which serves as the 
terminal node for the data packets communicated 
by a call. In this physical node embodiment, all 
nodes 12 include sufficient intelligence to route the 
data packets to this terminal node. Since nodes 12 
do not move significantly with respect to one an- 
other, only a minor amount of intelligence is re- 
quired. On the other hand, as the terminal node 
changes over the course of a call, the change in 
identity of the terminal node is communicated back 
to the party originating the data packets. This phys- 
ical node embodiment relies exclusively on the 
satellite jurisdiction indicated by circles 24 and 
does not use space regions 26. 

FIG. 3 shows a block diagram of a switching 
node, for example a satellite 12, used by constella- 
tion 11 (see FIG. 1). In the preferred embodiment 
of the present invention, all nodes 12 have a similar 
structure. Node 12 includes any number of tran- 
sceivers. For example, one transceiver 28 may be 
included for each cross link 16 (see FIG. 2). In 
addition, node 12 may include any number of 
earth-link transceivers 30, where each earth-link 
transceiver 30 serves a single CSO 18 or GCS 20 
(see FIG. 1). Node 12 may additionally include a 
subscriber-unit transceiver 32. Node 12 commu- 
nicates with any number of subscriber units 22 
(see FIG. 1), potentially in the thousands at any 
given instant, through transceiver 32. Each of tran- 
sceivers 28-32 couples to corresponding antennas 
34-38, respectively. 

Each transceiver 28-32 may include various 
sub-components common in the art, as illustrated 
in connection with cross-link transceiver 28a and 
subscriber unit transceiver 32. For example, each 
of transceivers 28-32 may include a receiver 40 
and a transmitter 42. Each receiver 40 couples to 
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an input buffer 44, into which input data are placed 
after the data are received at node 12 and de- 
modulated. For subscriber transceiver 32, input 
buffer 44 may be divided so that an individual sub- 

5 buffer is provided for each of the numerous chan- 
nels served by transceiver 32. Each transmitter 42 
couples to an output buffer 46, from which data are 
obtained for modulation and radiation or broadcast- 
ing away from node 12. For subscriber transceiver 

10 32 output buffer 46 may be divided so that an 
individual sub-buffer is provided for each of the 
numerous channels serves! by transceiver 32. 

Transceivers 28-32, along with various memory 
components and a timer 48, couple to a processor 

75 50. Processor 50 may be implemented using a 
single processor or multiple processors operated in 
a parallel architecture. Generally speaking, proces- 
sor 50 coordinates and controls transceivers 28 so 
that node 12 receives data communications -from 

20 cross links 16, appropriately distributes the re- 
ceived communications among output buffers 46, 
and transmits the communications back out into 
cross links 16. Data communications are also re- 
ceived from and transmitted to the surface of the 

25 earth via transceivers 30-32. Timer 48 is utilized to 
synchronize processor 50 and node 12 with timing 
constraints imposed by network 10 (see FIG. 1). 

The memory components of node 12 are con- 
figured to include a logical channel identification 

30 (LCID) table 52. Table 52 associates LCID values, 
discussed below, with output buffer addresses of 
transceiver 32 in a one to one correspondence. 
The addresses included in table 52 directly cor- 
respond to a channel used to transmit communica- 

35 tions to a subscriber unit 22. In other words, by 
writing data in the output buffer 46 of transceiver 
32 at the location specified by an address in LCID 
table 52, a particular traffic channel assigned to a 
particular subscriber unit 22 is selected. 

40 The memory components are further config- 

ured to include a routing look up table (RLUT) 54, a 
neighbor service map or list 56, a routing code 
table 57. and other memory 58. Generally speak- 
ing, RLUT 54 contains one data element for each 

45 possible routing code that may be received in a 
data packet at node 12. The data element asso- 
ciated with a data packet's routing code identifies 
which cross link 16 (see FIG. 2) to use in routing 
the data packet away from node 12 to its intended 

so location. Alternatively, the data element may inform 
node 12 that the data packet has reached its in- 
tended destination. 

Neighbor service map 56 records LCID values 
assigned to calls for which neighbor nodes 12 are 

55 new terminal nodes, status data characterizing the 
traffic carrying capacity of the cross links 16 to 
those nodes, and which CSOs 18 and GCSs 20 
(see FIG. 1) being served by those nodes. New 

5 
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terminal nodes are nodes to which data packets 
have been handed in the physical node embodi- 
ment of the present invention. RLUT 54 and map 
56 are discussed in more detail below. 

Routing code table 57 associates LCID values, 
routing codes, and addresses of input buffer 44 for 
multichannel transceiver 32 in a one-to-one cor- 
respondence. The addresses included in table 57 
directly correspond to a particular channels used in 
up-linking data packets to node 12. Node 12 may 
append the LCID values and routing code to the 
data packets before transferring the packets to 
another entity in network 10. The routing code and 
LCID values are initially determined during call 
setup, preferably by a CSO 18 (see FIG. 1), and 
sent to node 12 in a network control message. In 
accordance with the physical node embodiment of 
the present invention, the routing code is repet- 
itively updated during the course of a call in accor- 
dance with network control messages received 
from nodes handling opposing ends of the calls. 

Other memory 58 includes data which serve as 
instructions to processor 50 and which, when ex- 
ecutec^by processor 50, cause node 12 to carry 
out procedures that are discussed below. Memory 
58 also includes other variables, tables, and 
databases that are manipulated due to the opera- 
tion of node 1 2. 

FIG. 4 shows a flow chart of a Background 
procedure 60, which is performed by node 12 to 
support the switching of data packets from any 
input buffer 44 to an appropriate output buffer 46 
(see FIG. 3). In the preferred embodiment of the 
present invention, all nodes 12 perform substan- 
tially the same procedure. Background procedure 
60 may be viewed as running continuously while 
nodes 12 simultaneously engage in other activities. 
Generally speaking, procedure 60 determines 
whether certain needs have arisen, then takes an 
appropriate action when the needs are detected. 

The flow chart shown in FIG. 4 is constructed 
primarily from the perspective of the space region 
embodiment, discussed above, of the present in- 
vention. Many tasks depicted in FIG. 4 may be 
omitted for the physical node embodiment of the 
present invention. On the other hand, the few tasks 
which may be omitted for the space region em- 
bodiment are illustrated in FIG. 4 with double-lined 
boxes. 

Procedure 60 performs a query task 62 to 
determine whether one or mor*e new RLUTs 54 
(see FIG. 3) need to be generated for use by node 
12. The space region embodiment of the present 
invention utilizes different RLUTs 54 to track the 
movement of nodes 12 over space regions 26 (see 
FIG. 2). Accordingly, a number, for example 10- 
100, of different RLUTs 54 are used every orbit, 
and each orbit's set of RLUTs 54 differs from the 
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set used in the previous orbit. Rather than con- 
sume an extensive amount of memory storing 
RLUTs 54 that are not being used, the present 
invention generates RLUTs 54 before they are 

5 needed. RLUTs 54 that are no longer needed may 
be overwritten in the memory of node 12. Accord- 
ingly, task 62 determines when a need for generat- 
ing a new RLUT 54 exists. 

The need to generate a new RLUT may be 

io determined in accordance with a variety of factors. 
For example, task 62 may determine that a new 
RLUT 54 needs to be generated a predetermined 
period of time before the new table will be used by 
node 12. Alternatively, task 62 may queue the 

75 generation of a new RLUT 54 when a stockpile of 
existing RLUTs 54 falls below a predetermined 
size. Or, task 62 may decide that all RLUTs 54 to 
be used in an upcoming orbit need to be generated 
when a node is over a polar region of the earth 

20 where communication traffic is low and node 12 
may easily spare processing power for the genera- 
tion of RLUTs 54. These and other considerations 
pertinent to the efficient operation of node 12 may 
be relied upon in task 62 to determine when a 

25 need exists for generating one or more new RLUTs 
54. 

When task 62 detects the need for generating 
one or more RLUTs 54, a task 64 generates the 
one or more RLUTs 54 and saves them in the 

30 memory of node 12. Task 64 may be performed 
immediately after task 62, or may be performed 
later in a separate process which has been queued 
by task 62. Each single RLUT 54 associates a few 
bits of data with each possible space region 26 

35 (see FIG. 2). The data saved in RLUT 54 represent 
a link identifier (ID). The link ID specifies which of 
cross links 16 (see FIG. 2) to use in routing a data 
packet to the space region identified by a routing 
code. Alternatively, the link ID may inform node 12 

40 that the data packet might have reached its des- 
tination space region and that perhaps no cross 
link 16 should be used to transfer a data packet 
away from a node 12. 

The precise algorithms used to generate 

45 RLUTs 54 are not critical to the operation of the 
present invention. For example, a node 12 may 
simulate the position of itself and its neighbor 
nodes in constellation 11 with respect to all space 
regions 26 (see FIG. 2) at a representative point in 

so time for the RLUT 54 being generated. Then, node 
12 may, for simulated data packets routed to all 
possible space regions, determine the shortest or 
most direct path from the simulated position. Alter- 
natively, node 12 may receive data from a control 

55 station, such as GCS 20 (see FIG. 1), which can be 
. expanded to generate one or more RLUTs 54. 
Furthermore, nothing prevents the generating al- 
gorithms from incorporating special case rules. For 

6 



11 



EP 0 563 572 A2 



12 



example, routing algorithms may be configured to 
slightly favor in-plane routing over cross-plane rout- 
ing and even to weigh this bias toward favoring in- 
plane routing differently at polar latitudes when 
compared to more equatorial latitudes. 

Background procedure 60 performs a task 66 
to determine whether a need exists for switching 
from a currently used RLUT 54 to a new RLUT 54. 
Preferably, a single RLUT 54 is activated for a 
predetermined period of time, for example one to 
ten minutes. Task 66 may desirably determine 
when this predetermined period of time has ex- 
pired. When task 66 detects the need to switch 
between RLUTs 54, a task 68 saves a variable in 
the memory of node 12 which causes the next 
scheduled RLUT 54 to become the activated RLUT 
54. 

For the space region embodiment of the 
present invention, an appropriate RLUT 54 is ac- 
tivated at regular intervals. RLUTs 54 are gen- 
erated in advance and are ready and waiting to be 
activated when they are needed. A continuous 
stream of RLUTs 54 tracks the movement of node 
12. Tasks 62-66 may, but need not. be omitted in 
connection with the physical node embodiment of 
the present invention. The physical node embodi- 
ment routes data packets to specified physical 
nodes 12. The relative orientation of nodes 12 
remains static. Consequently, RLUT 54 may re- 
quire only minor changes during normal operations 
in connection with the physical node embodiment 
of the present invention. In the physical node em- 
bodiment, RLUT 54 may, for example, be gen- 
erated off-line and communicated to node 12 via a 
GCS 20 (see FIG. 1). 

Background procedure 60 performs a task 70 
to determine whether a need exists for processing 
a hand-off directive. A hand-off directive represents 
a message received from a neighbor node 12. The 
message informs a node 12 that the neighbor node 
sending the message has been a terminal node for 
one or more calls identified by the directive. As a 
terminal node, the neighbor node has been routing 
data packets associated with the one or more calls 
to one or more terminating units on or near the 
earth, such as subscriber units 22, CSOs 18, or the 
like. The hand-off directive also informs the node 
12 receiving the directive that the neighbor node is 
moving out of range for the terminating units and 
that the node 12 receiving the directive will, at 
some nearby point in time, be serving as the 
terminal node for the one or more calls. 

When task 70 detects a need for processing a 
hand-off directive, a task 72 takes an appropriate 
responsive action. Task 72 may be performed im- 
mediately after task 70 or later in a separate pro- 
cess which has been queued by task 70. When 
calls associated with subscriber units 22 (see FIG. 
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1) are being handed off, task 72 may store logical 
channel identification (LCID) values in LCID table 
52 and in routing code table 57 (see FIG. 3). An 
LCID value is a tag which each data packet in a 

5 call carries to uniquely identify the call, to identify 
the subscriber unit 22 to which the data packet is 
directed, and to identify a CSO 18 (see FIG. 1) 
which has some connection with the call. LCID 
values are discussed in more detail below. By 

w saving LCID values in LCID table 52 and call rout- 
ing table 57, node 12 assigns channels to the LCID 
values. 

When calls associated with CSOs 18 (see FIG. 
1) are being handed off, task 72 may store the 

15 identity of the CSOs in neighbor service map 56. 
By saving these CSO IDs in map 56, node 12 can 
send the bulk messages to the new terminal node 
which will assign a particular earth-link transceiver 
30 (see FIG. 3) to communications with the handed 

20 off CSOs. 

The responsive actions taken by task 72 may 
additionally include the communication -of a mes- 
sage back to the neighbor node to inform the 
neighbor node of new channel assignments for the 

25 calls of the subscriber units 22 (see FIG. 1) being 
handed off. The neighbor node may then inform 
the terminating units of the new channel assign- 
ments and a scheduled time for handing off to the 
new node 12. Handing off is relevant to routing 

30 data packets for both the space region and phys- 
ical node embodiments of the present invention 
because routing procedures, discussed below, 
compensate for the hand offs in delivering data 
packets to the nodes 12 which act as terminal 

35 nodes for calls. 

Background procedure 60 performs a task 74 
to determine whether a need exists for processing 
one or more neighbor service update messages. 
Neighbor service update messages convey LCID 

40 values of the calls for which the neighbor node 
serves as a new terminal nQde. The service update 
message may inform a node 12 of a neighbor's 
new acquisition of a channel or release of a pre- 
viously active channel. Channels may be acquired 

45 when, for example, a call has been recently setup 
or terminated or a call has been handed off. 

In either of the space region or physical node 
embodiments of the present invention, the neighbor 
service update messages convey link status data. 

so The link status data characterize the ability of a 
neighbor node to process traffic data received over 
a common cross link 16 (see FIG. 2). The status 
data may indicate that a cross link 16 has failed, 
that the neighbor node is experiencing exception- 

55 ally heavy data traffic and has a reduced capability 
to process new data traffic, or that normal commu- 
nication can take place. These status data are used 
in the present invention to prioritize data packet 
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traffic over the corresponding cross link. Neighbor 
status update messages may be exchanged be- 
tween neighbor nodes regularly. 

When task 74 detects a need for processing 
one or more neighbor service update messages, a 
task 76 saves the contents of the messages in 
neighbor service map 56 (see FIG. 3). Task 76 
may be performed immediately after task 74 or 
later in a separate process which has been queued 
by task 74. In the space region embodiment of the 
present invention, LCID values are preferably saved 
in a manner that allows them to be saved quickly 
yet accessed quickly at some future time given the 
LCID value. Node 12 additionally saves the status 
data in table 56. Of course, node 12 may detect 
that a cross link 16 (see FIG. 2) has failed on its 
own, without waiting to receive a neighbor service 
update message, and save this information in an 
appropriate status variable in table 56. 

Background procedure 60 performs a task 78 
to determine whether any calls have recently been 
initiated or terminated at node 12. When such a 
call status change is detected, node 12 performs a 
task 80, either immediately following task 78 or in a 
separate process queued by task 78. Task 80 
formats and sends a neighbor service update mes- 
sage, discussed above. The update message is 
sent to all neighbor nodes to inform the neighbor 
nodes of the change in call status. 

Background procedure 60 performs a task 82 
to determine whether a need exists for handing off 
one or more ongoing calls to a neighbor node. The 
precise technique used to determine when to hand- 
off calls is not important to the present invention. 
Node 12 may, for example, base the hand-off de- 
cision on Doppler characteristics, timing concerns, 
signal strength, and the like. Those skilled in the art 
will appreciate that such factors may be used to 
suggest when the entity being communicated with, 
such as a subscriber unit 22 (see FIG. 1), has 
reached a threshold distance away from node 12 
and is receding. 

When task 82 determines that a hand-off is 
needed, a task 84, which may be performed imme- 
diately after task 82 or later in a separate process 
queued by task 82, is performed. Task 84 formats 
and sends a hand-off directive to the neighbor 
node receiving the handed off call. Following task 
84, a task 86 may be performed to inform neighbor 
nodes of the change in call status resulting from 
the hand-off. 

A tasks 88 is performed for the physical node 
embodiment but may be omitted for the space 
region embodiment. Task 88 formats and sends a 
new destination directive to the opposite terminus 
of the call being handed off. The new destination 
directive is sent to a node of network 10 that is 
controlling the opposite terminus of the call, such 



as a CSO 18, GCS 20, or another node 12 through 
which a subscriber unit 22 is directly communicat- 
ing (see FIG. 1). This node of network 10 is the 
one that has originated the data packets for which 
5 node 12 has been the terminal node. The new 
destination directive instructs this termination node 
to alter the routing code it includes in data packets 
to identify the neighbor node receiving the handed 
off call. After this termination node receives and 

10 responds to the new destination directive, con- 
stellation 11 (see FIG. 1) will begin routing the 
call's data packets to the receiving neighbor node. 

Node 12 receives such new destination direc- 
tives with respect to data packets received directly 

15 from a subscriber unit 22 and transferred onto 
another node of constellation 1 1 (i.e. data packets 
entering constellation 1 1 from a subscriber unit 22). 
The new received routing code is stored at an 
appropriate location within routing code table 57 

20 (see FIG. 3). The appropriate location may be 
determined by looking up the entry in table 57 that 
holds an LCID value included in the directive. After 
revising table 57, node 12 will append the new 
routing code on call data packets received from 

25 subscriber unit 22 before transmitting them onward 
within constellation 11. CSOs 18 and GCSs 20 may 
perform a similar procedure in response to the 
receipt of new destination directives. Accordingly, 
call data originating from a public switched tele- 

30 communications network or the like and being 
transmitted to constellation 11 through a CSO 18 or 
GCS 20 may track changes in routing codes. 

After task 88, a task 90 saves the identity of 
the call and of the neighbor node receiving the call 

35 in neighbor service map 56 (see FIG. 3). By saving 
a record of the call hand-off, node 1 2 can route 
data packets to their correct terminal node after the 
hand-off occurs, even though the data packets may 
include a stale routing code. 

40 As shown in FIG. 4, program control for Back- 

ground procedure 60 continually repeats after per- 
forming selected ones of tasks 62-90. Thus, the 
contents of RLUT 54, LCID table 52, and neighbor 
service map 56 are kept current in the memory of 

45 node 12. Of course, those skilled in the art will 
appreciate that many of tasks 62-90 may be per- 
formed simultaneously or in a different order than 
indicated in FIG. 4. Moreover, those skilled in the 
art will appreciate that node 12 may perform addi- 

50 tional tasks not related to routing in Background 
procedure 60. 

FIG. 5 shows a flow chart of a Switch proce- 
dure 92 performed by a single node 12 in con- 
stellation 1 1 (see FIG. 1 ) to support the routing of 

55 communications. In the preferred embodiment of 
the present invention, all nodes 12 perform sub- 
stantially the same procedure. A task 94 performed 
by procedure 92 obtains a data packet. The data 
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packet may be obtained from any one of input 
buffers 44 (see FIG. 3). Procedure 94 may be 
performed multiple times simultaneously by mul- 
tiple processors dedicated to serving their own 
input buffers 44 or by a single processor which 
serves all input buffers 44. Accordingly, the particu- 
lar data packet obtained in task 94 is simply any 
data packet received at node 12 from any source, 
such as a neighbor node 12, a CSO 18 (see FIG. 
1), a subscriber unit 22, or the like. 

Data packets received from neighbor nodes 12, 
CSOs 18, or GCSs 20 (see FIG. 1) include a 
routing code and an LCID value. On the other 
hand, data packets received directly from sub- 
scriber units 22 (see FIG. 1) via input buffer 44 of 
multichannel transceiver 32 may not have such 
routing codes or LCID values. Accordingly, for such 
data packets a task 95 reads the address of the 
input buffer 44 of transceiver 32 from which a data 
packet has been obtained and accesses routing 
code table 57 using this address as a key. The 
routing code and LCID value stored in table 57 in 
association with this address is obtained and added 
or tagged to the received data packet. After task 

95, all data packets include routing codes and LCID 
values. 

The present invention accommodates the deliv- 
ery of a variety of data packet formats through 
constellation 1 1 . FIGs. 6 and 7 provide data format 
diagrams of two illustrative examples of data pack- 
ets 96 delivered via constellation 11 (see FIG. 1). 
FIG. 6 illustrates two independent data packets 96, 
and FIG. 7 illustrates a single data packet 96. Both 
of the FIG. 6 and FIG. 7 embodiments of data 
packet 96 include a single header 98 and a single 
routing code 100 for each data packet 96. Header 
98 carries data identifying a type characterization 
to be associated with data packet 96, a length to 
be associated with packet 96, and any other in- 
formation conventionally included in data packet 
headers. 

The type characterization may, for example, 
indicate that data packet 96 carries raw data or 
voice data. Those skilled in the art will appreciate 
that voice data and raw data may differ from one 
another in that voice data packets 96 may tolerate 
a lower degree of certainty in their delivery than 
raw data packets 96. In addition, the type char- 
acterization may be used to convey routing history 
data. Constellation 1 1 may then treat data packets 
96 which have already experienced routing prob- 
lems with a greater priority than packets 96 that 
have not yet experienced such problems. 

Routing code 100 is a relative short code, for 
example 4-12 bits and preferably 7-8 bits. Con- 
stellation 11 uses routing code 100 to quickly de- 
liver packet 96 to the terminal node for that packet 

96. A data format diagram for routing code 100 is 
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illustrated in FIG. 8. Routing code 100 preferably 
consists of two segments. A termination segment 
101 identifies the terminal node of constellation 11. 
In the physical node embodiment of the present 

5 invention, segment 101 directly identifies the node 
12 which is to serve as the terminal node. In the 
space region embodiment, segment 101 identifies 
a space region. A down-link type segment 103 
identifies the type of channel to use for routing the 

ro data packet 96 down to the earth. For example, a 
data packet may be routed to a subscriber unit 22 
(see FIG. 1) through multichannel transceiver 32 
(see FIG. 3) or to a CSO 18 or GCS 20 (see FIG. 1) 
through an earth-link transceiver 30 (see FIG. 3). 

75 Those skilled in the art will appreciate that nodes 
12 need not consult type segment 103 unless it 
first determines that it is. a terminal node for the 
data packet 96. 

With reference back to FIG. 6, in the FIG. 6 

20 embodiment each data packet 96 also includes a 
single LCID value 102 and a single set of payload 
data 104. Each node 12 may serve as a terminal 
node for thousands of independent communica- 
tions which need to be distributed among any 

25 number of termination units. Each independent 
communication is conveyed by any number, often 
in the thousands, of data packets 96, and each 
communication's data packets are received at the 
terminal node in a relatively arbitrary order. LCID 

30 value 102 identifies the specific termination unit to 
which the data packets 96 should be routed. 

FIG. 9 illustrates an exemplary data format 
diagram of LCID value 102. As shown in FIG. 8, 
LCID value 102 may include a sequence number 

35 component 106 and a CSO ID component 108. 
CSO ID 108 uniquely identifies the CSO 18 (see 
FIG. 1) which created the LCID value 102 and 
which has a managing interest in the communica- 
tion. Sequence number 106 identifies a particular 

40 call or registered subscriber unit 22 that is asso- 
ciated with that CSO 18. Each CSO 18 preferably 
insures that it activates rio two identical sequence 
values at the same time. Accordingly, by taking 
CSO ID 108 with sequence number 106, LCID 

46 value 102 uniquely identifies a termination unit to 
which a data packet 96 is being sent. 

With reference back to FIG. 6, header 98, 
routing code 100, and LCID value 102 together 
represent overhead data included in each packet 

so 96. Generally speaking, data packets 96 are deliv- 
ered through constellation 11 for some purpose 
other than the communication of the overhead data. 
The overhead data are included primarily for pur- 
poses of control. On the other hand, the commu- 

55 nication of payload data 104 serves as the primary 
purpose for delivering packets 96 through con- 
stellation 11. Payload data 104 is not restricted in 
form and may represent digitized voice data, raw 

9 



17 



EP 0 563 572 A2 



18 



computer data, video data, and the like. 

The FIG. 7 embodiment of data packet 96 
differs from the FIG. 6 embodiment in that each 
packet 96 in the FIG. 7 embodiment may include 
any number of sub-packets 110. Each sub-packet 
110 may include its own header 112 to character- 
ize the length of the associated sub-packet 110. 
Each sub-packet 110 may include its own LCID 
value 102 and pay load data 104. In accordance 
with the FIG. 7 embodiment, each data packet 96 
may include multiple independent communications 
to be delivered to different termination units. Each 
of these multiple communications has its own LCID 
value 102 and pay load data 104. However, all of 
these communications are associated with a com- 
mon routing code 100. Nodes 12 in constellation 
11 that are not terminal nodes process only a 
single routing code 100 to route multiple indepen- 
dent sub-packets 1 1 0. 

With reference back to FIG. 5. after task 94 has 
obtained a packet 96 from an input buffer 44 (see 
FIG. 3) and task 95 has added a routing code and 
LCID value when needed, whether packet 96 is 
formatted in accordance with the FIG. 6 or FIG. 7 
embodiment or otherwise, a task 114 performs a 
table look up operation on RLUT table 54 (see FIG. 
3) using routing code 100 from packet 96 as a 
table index. Those skilled in the art will appreciate 
the speed with which a table look up operation may 
be performed. Thus, task 114 quickly obtains a link 
ID for the packet 96 obtained above in task 94. 

After task 114, a query task 116 determines 
whether to route the packet 96 over a cross link 16 
(see FIG. 2) or whether the node 12 performing 
task 116 might be the terminal node for the packet 
96. If the node 12 is the terminal node, then the 
packet 96 will be routed down to the termination 
unit for whom the packet 96 is intended, either 
directly through transceiver 32 (see FIG. 3) or 
indirectly via a transceiver 30 and CSO 18 or GCS 
20. 

For the space region embodiment of the 
present invention, task 116 preferably evaluates the 
link ID obtained in task 114 in making its deter- 
mination. On the other hand, for the physical node 
embodiment of the present invention, task 116 may 
evaluate routing code 100 itself. As will become 
apparent from the discussion below, task 116 can- 
not determine with certainty at this point that the 
node 12 performing task 116 is the terminal node 
for packet 96. If task 116 determines that node 12 
might be the terminal node for data packet 96, 
program control proceeds to a Terminal Node pro- 
cedure 118, discussed below in connection with 
FIG. 10. 

When task 116 determines that the node 12 
performing task 116 is not the terminal node, pro- 
cedure 92 verifies the link ID obtained above in 



task 114, appropriately disposes of the packet 96, 
and then loops to process another packet 96. In 
particular, a query task 120 determines whether the 
packet type, included in header 98 of the packet 96 

5 (see FIGs. 6-7), is compatible with the status of the 
Jink ID obtained above in task 114. The compatibil- 
ity may be resolved by a comparison operation. 
The status of the link may be obtained from neigh- 
bor service map 56 (see FIG. 3). As discussed 

io above in connection with Background procedure 
60, this status indicates the quality of the cross fink 
16 (see FIG. 2) identified by the link ID, indicates 
the ability of the recipient neighbor node 12 to 
process the packet 96 due to traffic congestion, 

75 and is kept current by Background procedure 60. 
In the vast majority of cases, packet 96 will be 
compatible with the status of the cross link 16 
indicated by the link ID. 

When task 120 finds compatibility, a task 122 

20 moves the packet 96 to the output buffer 46 asso- 
ciated with the transceiver 28 (see FIG. 3) indicated 
by the link ID. The packet 96 will automatically be 
transmitted to the corresponding neighbor node 12 
in due course. After task 122, program control 

25 loops back to task 94 to begin processing another 
packet 96. 

On the other hand, in some circumstances task 
120 may discover an incompatibility. The incom- 
patibility may result from a failure of a cross link 

30 16, from excessive traffic congestion at the neigh- 
bor node 12, or the like. When an incompatibility is 
discovered, a query task 124 determines whether 
another cross link 16 is available. If, for example, 
each node 12 supports six cross links 16 (see FIG. 

35 2) any one of four or five alternate cross links 16 
may be utilized in disposing of a packet 96 when 
the preferred cross link choice indicated by the link 
ID from task 114 is not available. Procedure 92 
loops to examine these alternate cross links 16, 

40 and task 124 determines whether to break the loop. 

When another cross link 16 is available, a task 
126 changes the link ID to one that corresponds to 
one of the alternate cross link choices. Task 126 
may use a predetermined algorithm in selecting 

45 which of the remaining cross links 16 is preferred. 
For example, task 126 may select the cross link 16 
immediately clockwise to the previously examined 
choice. Alternatively, RLUT 54 (see FIG. 3) may 
include a segment 128 which lists the alternate link 

so IDs in a preferred order of priority. In addition, task 
126 may desirably alter the type data included in 
header 98, if not previously altered in the loop, to 
indicate that the packet 96 is being re-routed. 

After task 126, program control loops back to 

55 task 120 to test the compatibility of the selected 
alternate cross link 16. Program control remains in 
the loop of tasks 120, 124, and 126 until a compati- 
ble cross link 16 is found or until all cross links 16 
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have been examined and found to be incompatible. 
As soon as a compatible cross link 16 has been 
found, task 122 moves the packet 96 to the output 
buffer 46 (see FIG. 3) for that cross link. When no 
compatible link 16 is found, task 124 switches 
program control to a task 130. Task 130 drops the 
packet 96, and procedure 92 then loops back to 
task 94 to process another packet 96. By dropping 
the packet 96, the packet 96 will not be sent 
beyond node 12 and will not reach its intended 
destination. However, in dropping packet 96 task 
130 may desirably keep statistics on the number of 
dropped packets 96. Preferably, the dropping of a 
packet 96 is an extremely rare occurrence and one 
which happens only in connection with lower prior- 
ity data packet types. 

Those skilled in the art will appreciate that the 
routing procedure discussed above in connection 
with procedure 92 compensates for link failures 
and for excessive data traffic congestion. When all 
nodes 12 in constellation 11 perform their own 
versions of procedure 92, data packets 96 are 
automatically rerouted as needed to compensate 
for (ink failures and congestion. 

FIG. 10 shows a flow chart of Terminal Node 
procedure 118. As discussed above in connection 
with task 116 of procedure 92 (see FIG. 5), proce- 
dure 118 is performed when task 116 determines 
that the node 12 performing procedure 92 might be 
a terminal node for the data packet 96 currently 
being processed. Procedure 118 resolves whether 
the node 12 actually is the terminal node for the 
data packet 96 and appropriately disposes the 
packet 96, including any sub-packets 110 (see FIG. 
7) therein. 

Procedure 118 performs a task 131 to obtain 
and save the down-link type segment 103 of the 
routing code 100. The down-link type specifies 
whether packet 96 is intended for a subscriber unit 
22, in which case it may be delivered through 
transceiver 32 (see "FIG. 3), or a CSO 18 or GCS 
20, in which case it may be delivered through one 
of transceivers 30 (see FIG. 3). After task 131, 
procedure 118 performs a task 132 to obtain an 
LCID value 102 (see FIGs. 6-8) from the packet 96. 
In connection with the FIG. 6 embodiment of pack- 
et 96, there is only one LCID value 102 to get. 
However, in the FIG. 7 embodiment of packet 96, 
each sub-packet 110 has its own LCID value 102, 
and task 132 obtains one of these LCID values 102. 

After task 132, a query task 134 evaluates the 
LCID value 102 to determine whether the channel 
identified by this LCID value 102 is currently being 
served by the node 12 performing procedure 118. 
When the down-link type saved above in task 131 
indicates that packet 96 is to be delivered to a 
subscriber unit 22, this evaluation may be per- 
formed by accessing LCID table 52 (see FIG. 3) to 
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determine whether the LCID value 102 is listed 
therein. If the LCID value 102 is listed in table 52, 
then the channel identified by the LCID value 102 
is being served by this node 12. In other words, 

5 this node 12 is the terminal node for the data 
packet 96 or sub-packet 110 with which the LCID 
value 102 is associated, and this node actually is 
the terminal node for the packet 96 or sub-packet 
110. On the other hand, when the down-link type 

10 saved above in task 131 indicates delivery to a 
CSO 18 or GCS 20, task 134 need only examine 
the CSO ID portion 108 (see FIG. 9) of LCID value 
102. If this node 12 is the terminal node for the 
data packet 96 or sub-packet 110, then portion 108 

is corresponds to one of transceivers 30 (see FIG. 3). 

When the channel or link indicated by LCID 
value 102 is being served by this node 12, a task 
1 36 moves the packet 96 or sub-packet 1 1 0 asso- 
ciated with the LCID value 102 to the appropriate 

20 output buffer 46 of a transceiver 30 or 32 (see FIG. 
3). The packet 96 or sub-packet 110 will automati- 
cally be routed to the indicated destination in due 
course. 

After task 136, a query task 138 determines 
25 whether the end of the packet 96 has been en- 
countered. Task 138 is more pertinent to the FIG. 7 
embodiment of packet 96 than the FIG. 6 embodi- 
ment because the FIG. 6 embodiment only permits 
one LCID value to be associated with each packet 
30 96. Nevertheless, when the entire packet 96 has 
not yet been disposed of, as is possible in the FIG. 
7 embodiment of packet 96, program control loops 
back to task 132 to process the next LCID value 
102 from the packet 96, When the entire packet 
35 has been disposed of, program control exits proce- 
dure 118 from task 138 and returns to procedure 
92 (see FIG. 5), where node 12 processes another 
packet 96. 

When task 134 fails to determine that this node 

40 12 is serving the channel or link indicated by the 
LCID value 102, a task 140 evaluates neighbor 
service map 54 (see FIG. 3) to identify which of the 
neighbor nodes is serving that LCID or CSO ID 
portion thereof. This node 12 might not be the 

45 serving node when a call has been handed off to a 
neighbor node and the termination unit sending 
data packets 96 has not yet responded to a new 
destination directive, as discussed above in con- 
nection with task 88 (see FIG. 4). Alternatively, in 

so the space region embodiment of the present inven- 
tion, several nodes 12 may serve a common space 
region 26 (see FIG. 2). 

Preferably, task 140 accesses map 54 using 
LCID value 102 or CSO ID 108 as a key. By 

55 accessing map 54, task 140 quickly determines the 
identity of the neighbor node serving the LCID 
value 102. In connection with the space region 
embodiment of the present invention, neighbor ser- 
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vice map 54 is kept current through the commu- 
nication of neighbor service update messages, dis- 
cussed above in connection with Background pro- 
cedure 60 (see FIG. 4). In connection with the 
physical node embodiment of the present inven- 
tion, neighbor service map 54 is kept current 
through the recording of hand-off data, as dis- 
cussed above in connection with task 90 (see FIG. 
4). 

After task 140, a query task 142 determines 
whether a serving neighbor node was found. If no 
neighbor node serving the LCID value 102 has 
been found, a task 144 drops the packet 96 or sub- 
packet 110, and program control proceeds to task 
1 38 to process the next sub-packet 1 1 0 or packet 
96. In dropping the packet 96 or sub-packet 110, 
task 14.4 may advantageously maintain statistics on 
dropped packets 96 and sub-packets 110. 

When task 1 42 determines that a serving 
neighbor node has been found, a task 146 alters 
the routing code to indicate this neighbor node. 
Task 146 is optional for the space region embodi- 
ment of the present invention because the neighbor 
node presumably shares service of a common 
space region 26 (see FIG. 2) with the node 12 
performing procedure 118. On the other hand, in 
the physical node embodiment of the present in- 
vention, task 146 will cause the neighbor node to 
determine that it might be the terminal node for the 
data packet 96 or sub-packet 110. 

After task 146, a task 148 moves the packet 96 
or sub-packet 110 to the output buffer 46 asso- 
ciated with the cross link 16 (see FIG. 2) to the 
indicated serving neighbor node. Task 148 may 
advantageously re-format a sub-packet 110 into a 
packet 96 prior to placing it in the output buffer 46. 
The packet 96 will automatically be sent to the 
appropriate neighbor node in due course. After task 
148, program control proceeds to task 138 to pro- 
cess the next sub-packet 1 10 or packet 96. 

In summary, the present invention dynamically 
routes communication signals. The dynamic nature 
of the present invention allows physical nodes 
through which communication signals are routed to 
change during the course of a call. A minimal 
amount of network resources are dedicated to rout- 
ing communication signals. A relatively small rout- 
ing code is included in each data packet being 
delivered through the constellation of nodes, and 
routing is performed, at least in part, based upon a 
table look up operation that utilizes only a relatively 
small amount of memory. Moreover, the present 
invention distributes routing decisions among net- 
work nodes. Consequently, it instantly and auto- 
matically responds to data traffic congestion and 
link failures, and automatically corrects for incorrect 
routing decisions. Furthermore, the present inven- 
tion disposes of data packets quickly to minimize 



delay in delivering communication signals between 
network entry and exit points. 

The present invention has been described 
above with reference to preferred embodiments. 

5 However, those skilled in the art will recognize that 
changes and modifications may be made in these 
preferred embodiments without departing from the 
scope of the present invention. For example, those 
skilled in the art will appreciate that the particular 

10 tasks discussed herein may be sequenced dif- 
ferently than described. Moreover, the precise tim- 
ing, orbital geometry, network topology, data code 
lengths, and other parameters discussed herein are 
presented as illustrative examples and are not to 

75 be viewed as limiting the scope of the present 
invention. These and other changes and modifica- 
tions which are obvious to those skilled in the art 
are intended to be included within the scope of the 
present invention. 

20 

Claims 

1. A method of routing a signal through a switch 
which serves as one node (12) in a constella- 

25 tion (11) of switching nodes, said method com- 

prising the steps of: 

receiving a data packet (96) having a rout- 
ing code (100) therein, said data packet repre- 
senting at least a portion of said signal; 

30 obtaining a link identifier (16) in response 

to said routing code, said link identifier specify- 
ing one of a plurality of communication links 
useable at said switch in routing said data 
packet away from said switch; and 

35 transmitting said data packet away from 

said switch over said one communication link. 

2. A method of routing a signal through a con- 
stellation (11) of switching nodes (12), said 

40 signal being delivered between two points that 

move with respect to said constellation, and 
said method comprising the steps of: 

receiving a data packet (96) at a first node 
of said constellation, said data packet having a 
45 routing code (100) and a logical channel iden- 

tification (LCID) value (102) therein, and said 
data packet representing at least a portion of 
said signal; 

sending said data packet to a second node 
so of said constellation, said second node being 

identified in response to said routing code; 

determining (116), at said second node, 
whether said second node might be a terminal 
node for said data packet, said determining 
55 step being responsive to said routing code; 

evaluating (134), when said determining 
step determines that said second node might 
be said terminal node, said LCID value to 
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determine whether a logical channel identified 
by said LCID value is served by said second 
node; and 

transmitting (148), when said second node 
does not serve said LCID. value, said data ■ 5 
packet away from said second node toward a 
neighbor node over a second communication 
link determined in response to said LCID val- 
ue. 

10 

3. A data packet switching node for routing a 
signal within a constellation (11) of switching 
nodes (12), said switching node comprising: 

a receiver (40) configured to receive a data 
packet having a routing code (100) therein, is 
said data packet representing at least a portion 
of said signal; 

means, coupled to said receiver, for ob- 
taining a link identifier (102) in response to 
said routing code, said link identifier specifying 20 
one of a plurality of communication links usea- 
ble at said switching node in routing said data 
packet away from said switching node; and 

a transmitter (42), coupled to said means 
for obtaining, for transmitting said data packet 25 
away from said switching node over said one 
communication link. 
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(54) Dynamic signal routing 

(57) Data packets are delivered through a constella- 
tion (1 1) of nodes (12) to a termination unit (18. 20, 22). 
The node where a packet leaves the constellation is a 
terminal node. Each packet includes a routing code. 
When a node receives a packet, it examines the routing 
code to determine if that node might be the packers ter- 
minal node. A table look up operation is performed using 
the routing code as an index to a routing table. The table 
identifies a link (16) to use in routing the packet away 
from the node to a neighbor node. The packet is also 
examined to verify compatibility between packet type 
and a selected link. When a node concludes that it might 
be a terminal node for a packet, it evaluates a channel 
identifier to determine if it is currently serving the party 
to whom the packet is directed. 
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